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Abstract:  The  Taetan  language  wet  designed  aa  an  experiment  to  see  whether  the  Ironman 
requirement  for  a common  (ugh- order  programming  language  could  be  satisfied  by  an  extremely 
simple  language.  The  result.  Tartan  substantially  meets  the  Ironmen  requirement.  We  believe  it 
is  substantially  simpler  than  the  four  designs  that  were  done  in  the  first  phase  of  the  DOO-1 
effort  The  language  definition  appears  in  a companion  report  this  report  provides  a more 
expository  discussion  of  some  of  the  language’s  features,  some  examples  of  its  use,  and  a 
discussion  of  some  facilities  that  could  anhanea  the  basic  design  at  relatively  little  coat  tr 
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1.  Notes  on  Important  Issues 

The  Tartan  reference  manual  i«  tha  definmj  document  for  the  Tartan  language.  However,  some  of 
the  facilities  designed  in  response  to  the  ironman  requirement  deserve  more  unified  and  expository 
explanations  than  can  tie  included  in  a reference  manual.  This  chapter  discusses  the  Tartan  solutions 
to  several  important  problems  posed  by  the  Ironman  requirement 

The  Tartan  language  draws  heavily  on  the  Pascal  tradition.  Both  the  reference  manual  and  these 
notea  assume  familiarity  of  PaacalHika  languages.  These  notes  also  assume  familiarity  with  the  Ironman 
requirements  [1]  and  the  Tartan  reference  manual  [2} 

1.1.  Vocabulary 

A Tartan  program  is  made  up  of  definitions,  declarations,  and  (executable)  statements.  A definition 
binds  an  identifier  to  a module,  routine  (function,  procedure,  or  process),  type,  or  exception:  it  is 
processed  during  translation.  A declaration  binds  an  identifier  to  an  object  (i.s,  a variable  or  veiue);  it 
is  processed  at  run  time,  usually  to  allocate  storage.  Executable  statements  are  elaborated  at  run  time 
to  effect  computations  — manipulation  of  values. 

Identifiers  can  be  bound  to  modules,  routines,  types,  objects,  statements,  and  exceptions.  Individual 
identifiers  are  qualified  with  the  names  of  the  modules  in  which  they  are  defined  in  order  to  avoid 
conflicts  with  names  declared  in  other  modules. 

The  computation  described  by  a program  is  carried  out  by  elaborating  tie  program.  We  use  the 
word  ’elaboration",  in  preference  to  ’execution*,  to  connote  actions  taken  during  translation  as  well  as 
those  taken  during  execution.  Elaboration  may  be  thought  of  as  an  idealized  direct  execution  of  the 
textual  version  of  the  program.  The  effect  of  elaborating  each  construct  in  the  language  is  given  in  the 
reference  manual. 

Although  the  language  prohibits  making  a declaration  that  gives  new  meaning  to  an  identifier  in  a 
given  scope,  duplicate  identifiers  might  arise  in  three  situations.  These  situations,  and  the  way  Tartan 
deals  with  them,  are: 

- The  same  identifier  is  exported  from  two  modules  The  ambiguity  is  prevented  by  name 
qualification:  All  identifiers  exported  from  a module  are  prefixed  with  the  name  of  the 
module  that  exported  them;  the  prefix  is  separated  from  the  identifier  by  an  apostrophe. 
Thus  if  identifier  x is  exported  to  the  same  scope  by  both  modules  M and  N,  we  write 

n*«  ! for  tha  x exported  froe  n 

N*x  I for  ths  x sxportsd  froe  N 

The  qualification  may  be  omitted  if  no  ambiguity  arises. 

- An  identifier  is  used  as  an  overloaded  routine  or  type  name  That  is,  the  same  routine  name 
is  given  several  definitions  with  different  numbers  or  typos  of  parameters  Operator 
overloading  is  permitted  to  that  similar  operations  on  diatinet  types,  particularly  infix 
operations,  can  be  given  the  same  names  The  identifiers  for  the  routines  or  types  are 
disambiguated  by  examining  the  parameter  types  and  choosing  the  routine  whose  formal 
parameter  types  are  matched  by  the  types  of  the  actuals  A similar  situation  exists  with 
identifiers  for  families  of  related  types  In  order  to  discuss  these  situations,  we  introduce  the 
notion  of  signature: 

- The  signature  of  a routine  is  the  routine  name  together  with  its  formal  parameter  types 
The  type  of  the  value  returned  by  a function  is  not  included  in  its  signature 

- The  signature  of  a type  is  its  simple  type  name  together  with  its  generic  characteristics 
Generic  characteristics  are  discussed  in  Section  1.5.1. 

- A literal  or  constructor  might  potentially  be  of  two  or  more  different  types  The  ambiguity  is 
resolved  by  qualifying  the  literal  or  constructor  with  the  intended  type,  Including  its 
attributes 
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Scopo  determines  (ha  intarpratation  of  identifiers,  to  all  tha  taxt  in  a given  laxicai  tcopo  tharaa  (ha 
tama  vocabulary  — definitions,  variables,  ate  Scopa  rules  pemst  tome  idantifiara  to  ba  uaad  with  tha 
sama  intarpratation  in  multipia  laxicai  scopes. 

Tha  axtant  of  a variabla  is  its  lifetime  --  tha  tima  during  which  it  affects  or  is  a (f acted  by  tha 
slab  oration  of  tha  program.  Tha  interaction  of  control  and  laxicai  structure  determines  axtant.  Binding 
is  tha  association  of  identifiers  with  program  entities  (objects,  modules,  routines,  types,  statements,  and 
exceptions).  Tha  bindings  in  affect  at  any  time  result  from  the  interaction  of  control  and  lexical  scope. 

1.2.1.  Scope 

Lexical  structure  is  imposed  on  Tartan  programs  by  blocks  and  modules,  which  delimit  laxicai 
scopes.  Thera  are  no  restrictions  on  the  ways  these  scopes  may  be  nested  Both  constructs  may  use 
identifiers  defined  in  other  scopes-,  both  may  define  identifiers  that  can  ba  used  in  other  scopes. 
Scope  rules  govern  the  legal  bindings  of  identifiers  in  a lexical  scope  to  program  entities;  they  also 
control  the  imparting  and  exporting  of  identifiers  to  other  scopes.  Slocks  and  modules  differ  only  in 
their  scope  rules  and  in  their  effects  on  the  extent  ol  variables.  Tartan  has  two  scope  rules; 

- An  open  scope  Inherits  (imports  automatically)  all  the  identifiers  that  are  defined  in  its 
enclosing  scape.  It  may  not  export  any  identifiers  to  its  enclosing  scope.  Blocks  are  open 
scopes  except  when  used  as  routine  bodies. 

- A closed  scope  inherits  all  identifiers  that  are  defined  in  its  enclosing  scope  except  those  for 
labels  and  objects.!  It  may  explicitly  import  identifiers  for  objects  (variables  and  constants), 
provided  they  have  global  extent  A dosed  scope  that  is  a module  may  export  identifiers  that 
name  variables,  definitions,  or  exceptions;  the  exported  identifiers  have  the  status  of  any 
other  identifiers  defined  in  the  enclosing  scope  All  modules  are  dosed  scopes,  as  are  blocks 
when  they  are  used  as  routine  bodies. 

Identifiers  that  are  exported  from  an  inner  scope  or  imported  from  an  outer  scope  have  the  status  of 
identifiers  defined  in  the  scope.  Redefinition  of  identifiers  within  a scope  is  not  permitted.  The 
convenience  of  being  able  to  do  so  does  not  offset  the  danger  of  confusion.  This  does  not,  however, 
prohibit  overloading  of  routines  names;  the  differences  in  signatures  suffice  to  prevent  confusion.  In 
addition,  the  same  identifier  might  be  imparted  with  different  meanings  from  two  different  monies; 
such  identifiers  sre  qualified  with  the  names  of  the  modules  in  which  they  were  defined  Thus  they 
are  net  duplicate  definitions.  Similsriy,  literals  and  constructors  are  qualified  with  their  types  to 
prevent  ambiguity.  In  either  case,  the  module  or  type  qualifier  may  be  omitted  if  no  ambiguity  arises. 

1.2.2.  Extent 


Extent  rules  govern  the  lifetimes  of  objects.  Extent  is  controlled  by  blocks,  independent  of  whether 
they  correspond  to  open  or  dosed  scopes.  Nothing  except  blocks  controls  extent  The  static  data  of  a 
block  ia  allocated  when  the  declarations  of  the  block  a re  elaborated  (in  lexical  order)  at  block  antry. 
It  ia  deallocated  when  the  block  is  exited  or  terminated  Note  that  modules  do  not  define  extents,  so 
the  extent  of  data  defined  in  a module  coincides  with  tha  extent  of  its  surrounding  block. 

Values  of  dynamic  types  point  to  dynamically  allocated  variables.  The  type  of  object  that  may  be 
pointed  at  is  pa>  of  a dynamic  type.  The  extent  of  dynamically  allocated  variables  is  coincident  with 
the  blocks  in  w .ch  the  associated  dynamic  types  are  declared  Since  type  nemes  are  not  accessible 
outside  the  blocks  in  which  they  are  defined,  no  references  can  outlive  the  block  with  which  the 
extent  Is  associated 


1 Literals  and  identifiers  for  variables  that  are  declared  manifest  are  inherited 
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1.3.  Modules  and  Routines 

Modules  and  routines  ara  dosed  scopes.  Modules  « arva  as  an  ancapauiation  mechanism,  protecting 
the  privacy  of  definitions  and  declarations  without  restricting  their  extant  Routines  ara  used  for 
program  structuring  and  abstraction  of  operators;  they  define  operations  that  may  be  invoked  during 
eiaboration  of  a program. 

1.3.1.  Modules 


A module  Is  a dosed  scope  that  allows  local  definitions  to  be  shared  without  making  them  public. 
It  also  servos  to  bundle  up  related  definitions  for  administrative  (program  organization)  purposes.  It 
may  export  Identifiers  for  definitions  and  objects  to  the  scope  in  which  it  is  defined  A module  has  no 
parameters; 

A module  is  purely  a scope-defining  device  Its  elaboration  takes  place  during  the  elaboration  of 
declarations  for  the  block  in  which  the  module  is  defined  This  elaboration  consists  of  elaborating  the 
definitions  and  declarations  of  the  module  in  lexical  ardor,  then  elaborating  the  statements  of  the 
module. 

A module  or  routine  inherits  identifiers  for  definitions  (modules,  routines,  types,  and  exceptions), 
literals,  and  manifest  objects  from  its  enclosing  scope.  It  may  expUd  tty  import  Identifiers  of  objects 
from  that  scope,  provided  the  objects  have  global  extant  A modulo,  but  not  a routine,  may  export 
identifiers  other  then  labels  to  its  endoaing  scope. 

1.3.2.  Routines 

A routine  is  a dosed  scope  whose  body  is  a Mock.  Thus  its  body  controls  extent  for  local 
declarations,  but  does  not  inherit  identifiers  for  variables  or  non-manifest  constants.  The  <formals>  list 
declares  the  identifiers  for  parameters. 

A routine  may  be  a function  (func),  which  returns  a value  and  has  no  visible  side  effects;  it  may  be 
a procedure  (proc),  which  can  modify  its  parameters  but  must  be  called  as  a statement;  or  it  may  be  a 
process,  which  is  a potent! ally-parallel  procedure.  Spedai  type-specific  routines  for  many  types  are 
listed  in  the  Tartan  Reference  Manual. 

The  symbols  for  the  unary  and  binary  operators  are  used  as  routine  names  in  order  to  provide 
overloaded  definitions  for  those  operations. 

If  a < bindings  in  a routine  header  is  omitted,  it  is  assumed  to  be  const  The  result  binding  may  be 
used  only  in  <formais>  lists  of  procedures.  Functions  are  permitted  to  specify  var  parameters  in  order 
to  avoid  the  copy  aasodated  with  const  I However,  as  noted  below,  visible  side  effects  on  such 
parameters  are  prohibited  No  duplication  of  identifiers  within  the  <formds>  list  is  permitted  Further, 
formal  parameter  names  may  not  conflict  with  dod orations  or  imports  in  the  routine  body. 

If  a routine  name  is  overloaded  the  definition  whose  signature  matches  the  call  is  selected 

During  elaboration  of  a function,  assignment  to  a variable  that  is  not  local  to  the  function  body  (or  to 
the  body  of  any  routine  it  invokes,  <S redly  or  indirectly)  is  permitted  only  if  the  function  is  never 
invoked  in  a scope  where  such  a change  is  mode  to  a variable  or  component  that  is  directly 
accessible  by  the  caller.  Such  variables  may  be  imported  by  the  taction  from  a module  within  which 
the  function  ie  defined  They  may  also  be  fields  of  var  parameters  if  the  type  of  the  parameter  is 
defined  in  the  seme  module  as  the  taction  snd  the  field  name  is  not  exported  An  example  of  the 
latter  case  appears  in  section  2.4. 

This  is  a compromise  solution  to  the  side-effect  problem.  Many  routines  are  quite  reasonably  coded 
as  value-returning:  Get  of  section  2.4,  monitoring  routines,  random  runber  generators,  and  Pop  for 
stacks.  However,  the  current  state  of  the  art  does  not  offer  a sharp  rule  from  distinguishing  safe  from 
unsafe  side  affects. 


tin  the  presence  of  parallelism,  it  mey  not  be  safe  to  optimize  sway  the  copy  of  a const  parameter 
even  If  the  routine  does  not  alter  it 
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Actual  parameters  ara  matched  with  formal  paramatart  positionally.  They  mutt  tatitfy  raatrictiont  on 
type,  binding  and  aliasing. 

- Tha  typa  ol  an  actual  par  am*  tar  it  accaptabio  if  ita  <typa  nama>  exactly  matchaa  tha  <typa 
nama>  of  tha  corraapondlng  formal  paramalar  Type  attributaa  (inatantiatlon  paramatart  of  a 
typa)  play  no  roia  in  typa  cheeking. 

- Tha  binding  of  tha  actual  parameter  la  acceptable  if  it  matchaa  tha  <binding>  of  tha 
corraaponding  formal  parameter  according  to  tha  following  niet: 


If  the  formal  parameter  ie 
var 
conat 
manifeat 
reault 


than  tha  actual  parameter 
<var  id> 

<expr> 

any  manifaat  <expr> 
<var  id» 


• Finally,  tha  aat  of  actual  paramatart  mutt  tatitfy  tha  following  nonaliaaing  raa friction:  A 

variable  may  not  bo  uaed  in  more  than  ona  var  or  reault  poet ti on  of  a tingle  procedure  or 

proceea  call.  For  the  purpoee  of  letting  thia  restriction,  imported  vari ablet  are  conti dared  to 

ba  var  paramatart. 


1.4.  Generic  Definitions 

A facility  for  making  generic  definition!  it  provided  in  order  to  allow  tha  programmer  to  write  a 
single  textual  definition  that  serves  at  an  abbreviation  for  many  doeely-related  specific  definitions. 
Modules  and  routines  may  be  defined  genetically. 

A generic  definition  ia  instantiated  by  referring  to  it  aa  tha  body  of  a module  or  routine  definition. 
Tha  affect  of  tha  inetantiation  ia  as  if  tha  generic  definition  wart  lexically  substituted  in  place  oi  the 
reference  to  it  That  ia,  tha  body  of  tha  module  or  routine  being  defined  becomes  a copy  of  tha 
generic  definition. 


1.4.1.  Writing  and  Using  Generic  Definitions 

A generic  definition  it  tyntactically  like  tha  corresponding  specific  definition  except  that  it  is 
prefixed  by  the  word  generic  and  it  may  have  a set  of  generic  parameters  (enclosed  In  square 
brackets)  after  the  name  of  the  construct  being  defined.  The  parameters  may  be  any  defined 
identifiers,  including  those  for  variables,  routines,  typos,  or  modules,  or  any  expression.  When  the 
generic  definition  ia  instantiated,  the  text  ol  the  actual  parameters  replaces  the  identifiers  that 
represent  tha  formal  paramatart.  Tha  substitution  is  dona  on  a lexical,  rather  that  a strictly  textual, 
basis.  That  ia,  the  identifiers  in  the  generic  definition  are  renamed  as  necessary  to  avoid  conflict* 
with  tha  identifiers  in  tha  actual  paramatart. 

For  example,  tha  collection  of  functions 

funs  F2(Xi  Intlyi  Inti  begin  y 2 • X and 

funs  F3(Xt  Intlyi  Inti  begin  y 3 e X an* 

funs  F4 (Xi  Intlyi  Inti  begin  y !•  4 • X end 

end  to  on 

can  ba  defined  by  tha  generic  definition 

generic  hint  F (flu I ti  IntJ  (Xi  Intlyi  Inti  begin  y i»  fkil  t e X end 
and  tha  specific  instantiations 

funs  F2  is  F C21 
tunc  F3  is  F C31 
funs  F*  Is  F C41 
end  so  on 

An  instantiation  of  a generic  definition  may  be  used  at  the  body  of  a specific  module  or  routine.  The 
usual  restrictions  on  defining  new  identifiers  apply  (o  (he  module  or  routine  being  defined  in  terms  of  a 
generic 

Generic  typa  definitions  arise  from  generic  modules.  They  are  instantiated  when  the  module  is 
instantiated.  Thereafter,  they  may  be  uaed  in  declarations  or  definitions. 
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If  the  ganarlc  daHnilion  has  generic  parameters,  the  actual  parameters  supplied  with  tha 
instantiation  must  hava  eorreponding  typas  and  be  syntactically  suitable  for  substitution 

If  a ganaric  definition  is  instantiated  more  than  ones  in  a scops,  ambiguous  names  may  be 
introduced.  Tha  usual  rules  for  resolving  such  ambiguities  apply. 

1.4.2.  Separate  Definitions 

Tartan  supports  separata  definitions,  and  potentially  separata  compilation,  in  tha  same  way  as  it 
supports  generic  definitions.  A proram  may  ba  broken  into  separately  defined  segments.  This 
decomposition  must  taka  piaca  in  tha  global  extant  Tha  units  of  separata  definition  are  mocUee  and 
routines.  The  definition 

module  Q is  sssumodfl) 

in  a segment  has  tha  effect  of  making  tha  semantics  of  tha  segment  tha  same  as  if  the  (separately 
defined)  text  of  Q had  bean  substituted  lor  Is  assumedd)*  Tha  identifier  I refers  to  a file,  library,  or 
other  facility  for  storing  separately  defined  segments.  The  relation  between  the  identifier  I and  that 
storage  facility  may  be  established  by  a pragma!. 

Suppose  we  went  to  develop  and  maintain  a program  with  the  fallowing  structure: 

bogin 

modulo  cons  bogin  X;  . . . suds 

modulo  MX;  bogin  import  X.Yt  smart  Z:  . . snd; 
modulo  M2s 

bogin  import  X.Zt 
export  Us 

msiduls  (13:  bogin  . . . snd: 
ondi 

vo r Yt  . . .1 

! Main  prograo  using  U,  X,  Y,  Z 

sods 

If  the  definitions  of  COM,  Ml,  and  M2  sro  stored  in  a librsry,  the  following  program  will  have  the 
same  effect: 


[ 


prog  Require  (CooOef. LIB.  COM.  TXT) : RsquirsiMlOsf .LlB.Ml.REL) : 

Require (M20ef .LIB.M2.RELI s gsrpt 
modulo  COn  is  wsi—od  (COMOsM  s 
modulo  Ml  is  sssumed  (MIDeO  s 
modulo  M2  is  sssumed  (M20sf)s 
vsr  Y : . . . s 

! Mein  prograo  using  U,  X,  Y,  Z 

and: 

We  assume  here  that  the  second  argument  of  the  Require  pregmat  is  interpreted  by  the  system  ae  a 
pointer  into  a library.  From  tha  standpoint  of  the  language,  it  is  a matter  of  optimization  whether  the 
separate  definitions  are  included  as  text  or  separately  translated  and  linked  la 

In  order  to  perform  independent  translations  of  a saparataly  dafined  module,  It  ia  necessary  to 
embed  it  in  an  environment  that  provides  the  definition*  it  depends  on  This  environment  must  form  a 
complete  proram.  The  translation  system  is  sssumed  te  provide  commands  for  selecting  which 
components  of  such  a translation  to  save  snd  for  determining  where  snd  in  what  form  they  ere  saved. 
In  the  examples  here,  we  will  simulate  that  facility  with  a pregmat  located  outside  the  program.  In  the 
example  above,  module  COM  does  not  depend  on  any  external  definitions.  In  order  to  compile  it 
separately,  we  write  simply: 


? 


prsg  Ssv*  (Coo. LIB. COM.  TXT)  s gsrpt 
begin 

modulo  COM:  begin  export  Xs  . . . sods 
end 

Module  Ml  depends  on  the  X exported  from  COM  and  the  Y declared  in  the  mein  program  To 
translate  Ml  separately,  we  must  therefore  write: 
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prig  Sevefm.LIB.fll.fiEUi  gar*i 

begin 

pr»g  Require  (CoaOef  .LIB.COTI.  TXT) ; garpt 

module  COn  it  wppiid  (COnOpf); 

module  Dll  begin  import  X,  Yj  paporl  Z|  . . . wWi 

var  Yj  . . .» 


If  moteie  M2  were  translated  monolithcally,  its  translation  environment  would  look  much  tha  tama. 
Suppoaa,  howavar,  that  tha  definitions  of  M2  and  M3  ara  to  ba  separated.  Thay  can  ba  translated 
independently  with  tha  following  two  programs: 

prag  Spva  <rC.LIB.fi2.REU  s garpi 


prag  RaouiraiCoaOaf  .LIB.COn.  TXT)  i RaouiratniOaf  .LIB.Hl.REU  t 
R*auir»(n30*f  .LIB.h3.REL)  i |«rpi 
madui*  COh  a wtumed  (CChOaili 
madui*  m a iwumed  iniOafh 
module  h2i 

begin  impart  X.Zi 
aapart  Ui 

modulo  rt3  a (turned  (TOOaf  I 1 


prag  Save  (h3, LIB. 113. REL)  i (arpi 
begin 

prag  Require  IConOaf  .LIB.CQH.  TXT)  i Require  (HlDef. LIB. fll.REL)  i |arp 
medula  COh  ia  wtumed  ICOhOeM  i 
module  hi  ia  returned  (niOaMi 
medula  f12t 

begin  import  X.Zi 
export  Ut 

I Only  tha  daciarationa  of  H2  that  ara  required  by  H3  appeer 
medula  h3i  begin  . . . andi 


1.5.  Types 


The  notion  of  type  ia  introduced  into  language*  to  govern  the  weya  operation*  are  applied  to 
objects.  Typea  determine  certain  propertiee  of  data  (value*),  including  what  operation*  on  the  value* 
are  legal  and  preciaely  what  their  effect*  are.  Every  object  ha*  a fixed  type.  Thi*  type  ia 
determinable  Aring  translation.  The  <type  name>  ia  determined  by  the  aignoture  of  the  type  a* 
deacribed  in  taction  1.5  2.  Tartan  provide*  certain  built-in  type*;  theae  include  both  aimpie  and 
compoaite  type*.  The  uaer  may  define  now  type*  on  the  baai*  of  theae  primitive*.  Both  u*ar -defined 
and  built-in  type*  are  uaed  to  anaure  that  the  actual  parameter*  paeaad  to  a routine  match  the 
corresponding  formal  parameter*.  The  type*  of  the  formal  parameters  are  also  used  to  construct  the 
signature  of  a routine  in  order  to  resolve  overloading  ambiguities. 

In  Tartan,  every  value  he*  exactly  one  type  This  type  is  determined 

• by  the  dederation  of  a variable  or  definition  of  a function 

- by  the  lexical  form  and  context  of  occurrence  of  a literal 

Typoe  appear  in  four  context*: 

- in  declaration*,  to  give  the  typo  and  attributes  of  an  object 

• in  type  definition*,  to  give  tha  base  raprasantation  of  a nawty-dafined  type 

- in  formal  parameter  list*,  to  restrict  tha  object*  that  may  bo  passed  a*  parameter* 

- in  function  definition*,  to  give  tha  type  of  the  result 
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1.5.1.  Characteristics  and  Attributes 

Soma  of  tha  properties  of  a typa  aro  the  same  for  all  vatuoa  and  object*  of  the  type.  These  are 
called  generic  characteristics  and  are  ditcuatad  below.  Other  properties  of  a type,  called  attribute*, 
may  differ  from  one  value  or  object  of  tha  type  to  another.  For  example,  in  Tartan  the  type  of  the 
valuee  used  to  index  the  element*  of  an  array  (tha  type  of  the  index  set)  i*  a generic  characteristic, 
whereas  the  exact  bounds  of  the  array  (which  value*  ars  in  tha  index  set)  are  attributes. 

The  aet  of  attribute  name*  associated  with  a type  and  the  types  of  the  corresponding  attribute 
values  are  given  in  the  definition  of  the  type.  For  example,  objects  of  type  fixed  have  attributes  Max, 
Min,  Precision,  and  Scale. 

Note  that  the  attributes  values  of  an  object  ars  not  part  of  its  type.  It  is  therefore  possible  to 
write  routines  that  operate  on  objects  with  different  attributes  For  example,  it  is  straightforward  to 
write  routines  that  operate  on  arrays  of  arbitrary  sizs 

It  ia  often  convenient  to  define  families  of  rotated  types  with  similar  properties,  and  in  which  the 
differences  can  be  captured  through  differences  in  generic  properties  A type  definition  parameterized 
in  this  way  can  be  cast  as  a generic  type  definition.  Members  of  the  family  with  distinct 
characteristics  are  distinct  types 

Generic  type*  are  introduced  through  generic  module  definitions  For  sxampta, 

generic  module  8 1 ocksc  (T : type]  ; 

type  Block  (T)  (Or dor t Int)  • srrsyfl. .Order)  of  Ti 
pros  Blocklttvsr  BiBlockCTDi  begin  . . . end 
end 

define*  a set  of  types  BJock{._]  and  a set  of  corresponding  procedures  The  definitions 

module  IntBlock  Is  BlocksrCIntl: 
module  Reel 8 lock  it  B I ocker (Rea I ] t 
module  rtyfl I ock  i*  Blocker  CflyType) : 

introduce,  respectively,  the  types 

Blockttnt]  (Orderttntl 
Block  (Real]  (Order:  (nt) 

B lock  (flyTypeJ  (Order:  (nt) 

each  of  which  has  an  Order  attributs  Note  also  that  tha  procedure  Btocklt  is  overloaded  to  operate 
on  ail  these  types,  and  that  it  Is  indifferent  to  the  Order  attribute  of  its  argument 

1.5.2.  Type  Names 

In  Tartan,  a <type  name>  may  be  either  a simple  identifier  or  an  identifier  inflected  with  additional 
type  names  The  <type  name>  so  farmed  captures  tha  signature  of  tha  type.  For  example,  the  <type 
name>*  in  the  example  above  are 

Block  (Int) 

B I ock  (Res  I ) 

Block  (hyType) 

Although  the  definition*  of  these  three  types  are  doseiy  related  (they  arise  from  instantiations  of  the 
seme  generic  nodule),  the  types  arc  entirety  distinct 

The  <type  name>*  for  the  primitive  scalar  «nd  simple  nonscalar  types  are  the  keyword*  used  to 
declare  them:  fixed,  float,  boolean,  latch,  char,  sat,  string,  actants,  fils 

The  <type  name>  for  an  array  declared  *array(s.b)  of  0*  is  *array[I^]",  where  I ia  the  <type 
neme»  of  a and  b.  Sea  taction  1.5.3  for  tha  derivation. 

The  <type  neme>  for  an  enumeration  declared  anum(l.l,L2r-ln]  is  *awn[LlJL2*-Jjt}. 

The  <type  neme>  for  an  activation  declared  activation  of  P ia  acttvation(P]. 

The  <type  neme>  for  a dynamic  type  declared  dynamic  T ia  dynamic  T. 

The  <type  name>  for  a record  typa  is  based  on  the  sequence  of  fiold  names  and  <typ*  name>s  in 
it*  declaration.  For  a record  declared  “r*cord(Fl:Tl,  F1T2,  FmTn]"  tha  <typs  name>  is 
"r#cord(Fl:TNl,  F2TN2,  FmTNn]",  where  th*  Fi  are  lists  of  fiold  names,  the  Ti  are  types,  and  the 
TNI  are  type  names  Bindings  in  the  declaration  do  not  appear  in  tha  typa  name.  Thus,  in  the  code 
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f ragman! 

pro*  Plvar  «:  racord  (».  0:R«al ) ) i ba(>n 
var  gt  record  (a.  b:  Raa  1 1 ; 
war  zi  racordtc, diRpa I ) : 


variable*  y and  z have  different  <type  name>«  and  only  y i*  acceptable  a*  a parameter  to  P. 

The  <type  name*  for  a variant  i*  "varianl(TT,Tl-»Vl,T?  >V2^,Tn-»Vn]",  where  TT  i*  the  <type 
name*  of  the  tag,  Ti  i*  the  ith  value  of  the  tag  type,  and  Vi  i*  the  <type  name*  that  correspond*  to 
the  ith  value  of  the  tag  type  A*  a result,  two  variant  <typ#»«  are  the  same  if  they  specify  the  same 
<type>*  for  all  value*  of  the  tag.  Thu*  for 


type  Color  - anum  trad,  green,  blue,  yel'oul; 

variant  TiColor  ten  red  •>  mint  an  blue  ->  g:n*r*lSI  an  When  ->  zt  array  (1.  .5)  ot  IntJ 


the  <type  name*  I*  'variant(Coior,  rad->lnt,  freen->aiTayfInt,Intl1  Wue-*Mark,  yeHow-»arrayfInt,IntJ* 

The  <type  name*  for  a defined  type  is  the  type  name  given  in  the  type  definition,  a*  illustrated 
above  for  Blockf...}. 


1.5.3.  Array  Types 


The  built-in  array  type  is  in  fact  * generic  family.  Array*  have  uniform  properties  in  that  every 
array  is  a structure  for  storing  a linear  homogeneous  fixed-length  sequence  of  values  indexed  by  a 
given  ordered  set  of  value*.  However,  arrays  with  different  element  types  or  different  types  of 
indices  are  distinct  types. 

This  particular  generic  family  of  types  is  so  common  that  Tartan,  like  most  languages,  provides 
special  syntax  for  it  There  is  a set  of  types  pre-defined  as  *array(IxType,EltType](r)“  where  IxType 
is  the  index  type,  EHType  is  the  element  type,  and  r is  a (subrange  of  IxType.  The  syntax  "arrayfr) 
of  EltType*  is  provided  as  an  abbreviation  for  each  such  type.  Thu*  "arrayd-lO)  of  float"  means 
'’array[ir>lfiloat](l..lO)m.  Its  type  name,  “arrayfint,lloatJ",  is  written  "arrayfintj  of  float".  Thus  if  we 
have  declared 


vsr  V:  array  (1..10)  ol  Float 
vsr  Bi  array  lrad..gr*«n)  ot  boot**! 


the  generic  type  of  both  B and  V is  array,  but  their  <type  name**  are  different  The  <type  name*  of 
B is  array{int,float],  whereas  the  <type  name*  of  V is  arrayfcolor, boolean). 

The  type  *array(A,B)  of  T”  is  an  abbreviation  for  *array(A)  of  arrayfB)  of  T*.  Similarly,  the  array 
accessor  "V(i,j)"  is  an  abbreviation  for  "V0XJ)“ 


1.5.4.  Declarations 


The  attribute*  of  a variable  become  fixed  at  the  time  of  its  allocation.  For  static  variables,  this 
occurs  during  elaboration  of  the  declaration  Variable*  ol  dynamic  types  do  not  themselves  have 
attributes.  The  dynamically  allocated  object*  they  refer  to  do,  however,  have  ettributee;  these  are 
supplied  whenever  a constructor  ie  executed 

The  declaration  of  a static  variable  must  provide  both  a <type  name*  and  values  for  the  attributes 
associated  with  that  type.  For  example,  the  declaration  *var  V:  array  (m..n)  of  Int",  which  ie  an 
abbreviation  for  "var  V:  array[Int,lnt](m..n)*,  computes  the  current  values  of  m and  n to  obtain  the 
range  of  the  index  set,  then  statically  allocates  a eatable  block  of  storage.  However,  the  program 
fragment 


type  Arrlnslnt)  • dynamic  array  II.. n)  *<  Inti 
vsr  Vi  Arri 
V i.  Arr  (5)  l)| 


allocates  the  variable  V with  type  Arr,  no  attributes,  and  ail  value*  undefined  The  declaration 
allocate*  a reference  to  V and  sets  it  to  nil.  The  constructor  dynamically  creates  a new  object  of 
type  array(lnt)  of  Int  with  subscript  range  attribute  *L5*  and  associates  this  object  with  variable  V. 
A subsequent  assignment  to  V might  use  a constructor  with  a different  bound 


1.5.5.  Type  Checking 


The  type  checking  rule  for  matching  actual  and  formal  parameters  it  baaed  on  the  type*  (but  not 
the  attributes)  of  the  parameters.  The  actual  parameter  it  acceptable  iff  the  <type  name*  from  its 
declaration  exactly  matches  the  <type  name*  ol  the  formal  parameter. 
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The  attribute*  of  the  value*  returned  by  a function  invocation  are  determined  immediately  before 
calling  the  function.  They  must  therefore  be  specified  in  term*  of  input  value*  of  the  function.  For 
example,  if  Str  i*  a type  with  attribute  length,  the  definition 


>unc  Cones  MS.  I : Str)R>Stri  begin  . . . end; 

would  not  be  legal,  since  the  attribute*  of  the  functional  result  are  not  specified.  The  following, 
however,  would  both  be  legal  (but  would  have  different  meanings): 

fun*  ConcetiS.Ti  Str(R:Str  (27)  i begin  . , , end: 

fun*  ConcatlS,  T:  S tr  IR:Str  (S.lsngth+T. Length! ; begin  . . . end: 

This  simplifies  the  implementation,  but  it  preclude*  the  definition  of  function*  that  return  value*  whose 
attribute*  can  only  be  determined  during  the  evaluation  of  the  function.  This  should  not  usually  be  a 
stringent  constraint;  in  the  worst  case  a dynamic  type  may  be  used  to  return  the  value. 

1.5.6.  Defining  Types 

A user  may  introduce  a new  type  into  his  program  with  a type  definition.  The  type  definition  itself 
merely  introduces  the  <type  nam*>  and  define*  the  representation  of  the  type.  Operation*  are 
introduced  by  writing  routines  whose  formal  parameter*  are  of  the  newly-defined  type.  Scope 
boundaries,  particularly  module  boundaries,  play  no  role  in  the  definition  of  the  type.  There  is,  as  a 
consequence,  no  notion  of  the  complete  set  of  operations  on  a type. 

A type  definition  may  be  parameterized  with  attribute*.  The  bindings  in  the  formal  parameter  list 
must  be  const  or  manifest  If  a <binding>  is  omitted,  it  will  be  assumed  to  be  const  The  names  of  the 
formal  parameters  of  the  type  are  available  throughout  the  elaboration  of  the  program  at  constants, 
called  attributes.  They  are  accessed  by  treating  the  <var  ident>  as  a record  and  tha  type  attribute  as 
a const  field  Attribute*  for  primitive  types  are  given  as  part  sf  tha  type  definition*. 

1.5.7.  Operations  on  New  Types 

Operations  on  new  types  are  introduced  by  routine  definitions.  These  may  be  either  routines  called 
with  normal  invocation  syntax  or  definitions  for  infix  functions.  In  order  to  make  it  possible  to  write 
basic  operations  on  the  new  type,  Tartan  provides  a means  of  applying  operations  of  the  underlying 
representation  to  objects  of  the  new  type.  Within  the  scope  in  which  the  type  is  defined,  the 
qualifier  Rep  may  be  used  (o  indicate  that  the  object  named  by  the  identifier  it  qualifies  is  to  be 
treated  as  if  it  had  the  underlying  type.  It  is  not  exportable  This  allows  operations  on  the  new  type 
to  be  written  using  operations  on  its  representation.  When  no  ambiguity  arises,  the  Rep  qualification 
may  be  omitted  For  example,  we  may  writ# 

type  Mark  • Int: 

fun*  "♦’(a.bt  flarklc: hark i begin  Rap’e  :*  Use's  ♦ Rsp’b  and: 

Rep  qualification  la  intended  to  be  used  within  a module  in  order  to  write  primitive  operations  and  to 
extend  operators  to  the  new  type.  It  is  obviously  possible  to  abuse  the  facility. 

An  assignment  operator  is  automatically  supplied  for  user-defined  types.  Although  it  may  be 
invoked  with  any  variable  and  value  of  the  type,  it  signals  tha  BadAssign  exception  if  the  attributes  of 
its  left  and  right  operands  are  not  identical  or  if  component-by-component  assignment  would  fail.  Sizes 
of  nonscalars  are  thus  guaranteed  to  be  compatible  Clearly,  assignment  may  be  well-defined  in  cases 
where  this  rule  disallows  il  Such  assignment  operator*  could  be  provided  if  user-defined  assignment 
were  compatible  with  the  requirements. 

When  a module  is  used  to  encapsulate  the  definition  of  a type  and  its  operations,  the  type  name 
and  some  of  the  operations  must  be  exported  from  the  module.  Types,  named  routines,  field 
accessors  for  records,  and  variables  are  exported  by  including  their  names  in  the  exports  list  of  the 
module.  The  right  to  apply  infix  operators,  constructors,  subscripts,  'all",  or  the  create  command  are 
exported  by  including  the  special  names  Tlnfix,  Tconstr,  Tsubser,  "Tall,  and  rcreate,  respectively,  in 
the  exports  list  Literals  of  enumerated  types  are  exported  automatically  if  the  types  are  exported. 

1.6.  Parallel  Processes 

Parallel  processes  are  controlled  with  data  o(  two  types  — activations  of  processes  and  actnames, 
or  names  of  activations.  An  activation  variable  must  be  an  instantiation  of  a given  process;  it  may 
contain  at  most  one  activation  of  that  process  during  its  lifetime.  An  setname  variable  is  a pointer  to 
an  activation.  A single  setname  may  b*  associated  with  different  instantiations  of  different  processes 
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from  time  to  tima. 

Procaaaaa  ara  similar  to  procedures.  The  syntactic  distinction  between  procedures  and  processes  is 
imposed  because  we  believe  the  potential  for  parallel  execution  should  be  indicated  explicitly  in  the 
program 

Note  that  activations  and  actnames  control  only  the  parallel  control  flow  of  the  program  No 
synchronization  is  supplied  with  the  processes;  this  must  be  coded  explicitly  with  the  primitive  latches 
or  with  other,  nonprimitive  synchronization. 

1.6.1.  Activations 


Activations  of  processes  are  used  to  control  parallel  or  pseudo-parallel  execution  of  instances  of 
the  named  process.  If  P is  a process  and  x is  a variable  of  type  activation  of  P,  then  x can  contain  an 
independently-executing  instantiation  of  P,  called  an  activation  of  P.  An  activation  of  P may  be  in  one 
of  several  states: 

- Mint:  A mint  activation  has  not  yet  been  started  up  as  a process.  The  only  operations  that 
can  be  performed  on  it  are  create,  NameOf  (i.e,  the  function  that  returns  the  activation’s 
name),  and  the  state-interrogation  predicates.  A newly-declared  activation  or  actname  is 
initialized  to  the  literal  mint 

- Suspended:  A suspended  activation  can  have  no  effect  on  any  objects;  in  essence,  it  is  not 
executing  and  will  not  execute  until  it  is  activated  (see  below). 

- Active:  An  active  activation  is  one  in  which  it  is  feasible  for  elaboration  to  take  place.  It 
may  affect  objects,  and  its  dock  may  advance 

- Dead:  A dead  activation  admits  of  no  further  elaboration.  It  cannot  be  revived  and  it  can  play 
no  further  role  in  the  program.  An  activation  becomes  dead  when  it  exits  normally,  when  it 
fails  to  handle  an  exception  raised  during  its  elaboration,  or  when  it  is  named  by  a Terminate 
command. 

The  extent  of  an  activation  variable  is  determined  by  the  block  in  which  it  is  declared  When  such 
a variable  is  declared,  an  activation  of  the  named  process  is  instantiated,  set  to  state  mint,  and 
associated  with  the  declared  process  name.  The  immediately  enclosing  block  cannot  be  exited  until  all 
activations  declared  within  it  are  dead  or  still  mini  An  activation  is  associated  with  exactly  one 
process,  but  a single  process  may  be  instantiated  multiple  times  for  different  activations. 

If  x has  been  declared  as  an  activation  of  P and  is  in  mint  state,  the  statement  "create  x(...)" 
creates  a new  activation  of  P in  suspended  state.  The  formats  of  P are  bound  to  the  actuals  supplied 
in  the  create  in  the  same  way  as  actuals  are  bound  lor  a procedure  call.  If  a process  takes  a var 
parameter,  the  corresponding  actual  parameter  must  have  extent  at  least  as  great  as  the  activation’s 
extent.  For  purposes  of  this  rule,  an  activation  passed  as  a var  parameter  to  a routine  is  treated  as  if 
its  scope  were  that  of  the  process  definition.  As  a result,  translators  need  no  dynamic  extent  checking. 

Except  for  create,  all  operations  on  activations  are  syntactically  routine  invocations.  These  routines 
conrof  the  processes  and  hence  the  parallelism  by  changing  and  interrogating  the  state  of  individual 
activations.  They  are  listed  in  the  Tartan  Reference  Manual. 

1.6.2.  Fork  and  Join 


The  extent  rules  require  each  activation  to  complete  (exit  or  terminate)  or  stilt  be  mint  before  the 
block  in  which  it  is  declared  can  exit  This  provides  an  implicit  join  operation  A fork  can  be 
obtained  with  a series  of  creates  and  activates.  For  example, 

begin 

process  p (const  »:Intl|  begin  . . . end; 

vsr  V;  array  (1 . . 10)  ot  activation  oi  Pj 

for  i in  1..  10  do  create  V[i)(i):  activate  (P(i ) ) ed 


declares  ten  activations  of  a process,  uses  create  to  start  them  up  with  different  values  of  the  input 
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variatoi*  (using  the  loop  index  as  the  input  value  at  well  •*  to  index  the  array  of  activation*),  move* 
each  activation  into  active  ttate,  and  wait*  it  the  and  o!  the  block  for  the  activations  to  terminate. 
After  starting  the  activation*  of  P,  the  main  program  may  continue  with  other  computation,  monitor  the 
progress  of  the  aclivations,  or  simply  wait  for  the  activation*  to  terminate. 

1.6.3.  Activation  Names 


An  actname  may  name  any  activation  An  actname  variable  i*  not  permanently  associated  with  any 
particular  activation,  and  there  i*  no  requirement  about  the  state  ol  the  activation  named  by  an 
actname  when  the  extent  of  that  actname  variable  is  exited  or  terminated  This  permits  routine*  to 
operate  on  activations  without  knowing  what  processes  they  are  activation*  ol.  For  example,  it  makes 
it  possible  for  routines  that  are  generally  useful  for  managing  activation*  to  be  defined  in  a large 
scope  without  requiring  ail  process  definitions  and  activation  variables  to  include  that  scope.  A single 
activation  may  be  named  by  more  than  one  actname.  There  is  no  dangling  reference  problem:  Even 
though  the  reference  (actname)  may  outlive  the  activation,  the  activation  will  be  deed  (terminated  or 
mint)  after  its  block  is  exited  (and  thus  no  unexpected  computational  result*  can  be  induced).!  Since 
the  create  command  cannot  be  applied  to  an  actname,  the  process  cannot  be  restarted 

Activation  variables  may  not  be  the  objects  of  assignments  and  may  not  appear  in  result  parameter 
positions.  However,  each  activation  has  a name,  of  typo  actname.  This  name  may  be  obtained  by 
invoking  the  function  KameOf  on  an  activation.  All  operation*  on  activation*  except  create  extend  to 
actname*.  Thus,  Suspend(Nam*Of(x))  has  the  same  effect  a*  Suspend) x)  The  special  operation  Me<) 
returns  the  actname  of  the  current  process.  In  addition,  actname  variable*  may  appear  in  assignments. 
(Thus  users  may  write  programs  that  operate  on  anonymous  activation*,  for  example  to  do 
special-purpose  scheduling.)  The  extent  of  an  actname  variable  may  dominate  the  extent  of  the 
activation  it  names.  If  that  situation  arises,  after  the  extent  of  the  activation  is  exited,  the  actname  will 
refer  to  a terminated  process,  and  no  damage  can  be  done. 

The  Notify  operation  on  activations  or  actname*  signals  the  Terminate  exception  in  the 
currently-executing  statement  of  the  activation  named  by  the  command  Within  the  activation  in  which 
it  is  raised.  Terminate  is  treated  like  any  other  exception.  This  is  the  only  mechanism  provided  by 
Tartan  that  enable*  on*  activation  to  interrupt  another. 

1.7.  Unresolved  Issues 

We  did  not  obtain  solutions  to  all  the  Ironman  requirements  in  the  two-month  period  allotted  to  this 
design.  In  this  section  wo  sketch  the  way  we  would  address  the  unresolved  issue*. 

1.7.1.  Machine-Dependent  Code 

Machine-dependent  cod*  present*  two  issue*:  dsfinition  of  operation*  and  definition  of  data  Tartan 
will  permit  separately-defined  machine  dependant  routine*  to  be  incorporated  in  the  same  way  as 
other  separate  definitions.  This  is  consistent  with  the  Steelman  requirement  We  have  not  yet 
addressed  the  problem  of  machine-dependent  declaration*  (data  layout). 

1.7.2.  Simulation 

We  believe  Tartan  supports  a programmed  solution  to  the  simulation  requirement  For  example,  the 
facilitie*  of  Simula  60  can  be  provided  for  Tartan  programs: 

- Tartan  activations  can  serve  the  same  function  as  Simula  activities. 

- A coroutine  call  discipline  may  be  programmed  using  the  routines  Activate  and  Suspend. 

- A scheduler  that  manages  simulated  time  can  be  programmed,  again  using  operations  on 
activation*. 


lThe  activation  record  itself  may  be  allocated  in  the  heap;  it  does  not  become  eligible  for  garbage 
collection  until  ail  references  have  been  broken.  Thus  no  actname  can  become  an  uncontrolled  pointer 
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1.7.3.  Definition  of  Integers 

In  the  reference  manual  wa  chose  Iliad  n a primitive  and  dafinad  Int  aa  a special  caaa  by 
c hooting  attributaa  appropriataly.  Wa  baliava  it  it  peaaibla  to  Iraat  int  at  primitiva  and  datina  Fixed 
aa  nonprimitiva  by  aaaociatlng  range/precision  bookkeeping  with  tha  operations 

1.7.4.  Low-Level  Input  and  Output 


Wa  included  file  at  a primitive  data  type  but  <M  not  tpacify  ita  properties  Given  tha  ability  to 
write  machine-dependent  coda  to  accatt  tha  devicee  and  tha  ability  to  uee  procattat  to  maintain  atata 
(and  hence  to  avoid,  for  example,  re-opening  a file  lor  each  operation),  wa  baliava  a wide  variety  of 
low-level  I/O  can  be  implemented  effectively. 

1.7.5.  Higher-Level  Synchronization 

Numerous  synchronization  discipline*  have  been  proposed  or  are  in  active  use.  Nona  of  them 
clearly  dominates  tha  others;  none  is  appropriate  in  ail  cases.  We  have  elected  to  provide  a vary 
primitive  synchronization  tool,  a latch  Conceptually,  a latch  is  a spinlock;  failure  to  siaza  such  a lock 
does  not  necessarily  release  tha  processor.  By  choosing  a primitiva  mechanism,  wa  hope  to  avoid 
pre-empting  tha  implementation  ol  higher-level  synchronization  techniques  Wa  believe  alternative 
mechanisms  can  be  implemented  a If  actively  in  Tartan  Indeed,  we  baliava  that  this  is  tha  correct 
approach. 
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*2.  Programming  Examples 

Several  sample  Tartan  programs  are  presented  here  Some  show  the  use  of  various  features  of  the 
language;  others  provide  programmed  (nonprimitive)  solutions  to  certain  Ironman  requirements. 

2.1.  Simple  Static  Data  Type 

A circular  buffer  is  implemented  in  a vector.  The  definition  is  generic  in  the  type  of  the  elements, 
the  length  of  the  buffer  is  an  attribute  of  the  type.  This  implementation  keeps  a pointer  to  the 
current  head  of  the  buffer  (Head)  and  a pointer  to  the  element  one  past  the  current  end  of  the  buffer 
(Tall).  All  arithmetic  on  these  pointers  is  done  modulo  the  size  of  the  btdfer. 

generic  module  CirculsrBuf  fere  IT i type) i 

exports  CtrcBuMT),  1 type,  attribute  Size 

Clear,  Append,  Reeove,  Full,  Eapty.  ! routines 

BufOvfl;  I deception 

type  ClrcBuf  (T)  (Size:  lot)  ■ reeerdiBft  vraylB. . Size-1)  ct  T,  Hoad.Talli  Intli 

exception  BufOvfl  i 

prec  Cleartrecult  Ct  CireSufCTUt  begin  C.Headt-Bt  C. Tcllt-8  ondt 

pro*  Append  (var  Ct  CircSuftT].  tenet  VeltT)| 
begin 

if  Full  1C)  then  signal  BufOvflt 

C.Bf  (C. Toil)  t-  Veit 

C.Tall  !•  eodlC. Tel  1+1,  C . S > ze > : 

ends 

prec  Renovetvar  CiCircBuf  tT) . recull  Veit  T)| 

A- 1— 

mart  - EnptyiOi 

Vji  t-  C.Bf (C. Head! t 

C.Heed  )•  eod (C.Hccd+1 . C.Sizch 

ends 

func  Ful  I (CiCircBuf  CTUFtboofeen:  begin  F s>  (C.Heed  . eodtC.Tel  1*1.  C.SIze))  endt 
turn  Eopty (CiCircBuf  tTI  I Et bed  inn  begin  E t>  (C.Heed  • C.Tall)  endt 
end  ! nodule  ClrculcrBuf fere 


2.2.  Simple  Dynamic  Data  Type 

Wo  define  a liet-procaasing  module.  Each  liet  caH  contain*  a value  of  a specific  typo;  the  definition 
of  the  modulo  ie  gonoric  in  this  typo. 

generic  module  UitOdf  (Tttype)  t 

begin 

exporta  List  IT),  Oeta.  Next,  I type  end  field  neede 

Clear,  Ineert.  Delete,  Laeti  I rout  Inca 

type  LletCT]  ■ Synsmis  record  COetatT,  NextiLlst tT)) t 

prec  Cleeriroeult  LiLlet(T])|  begin  L t«  nil  endt 

pree  Insert  (ver  El  tiLiat  (T) , ValtTli 
begin 

H El  t - nil 

then  Elt  t-  Liet  IT)  • (Val.nil) 

else  Elt. Hex t t-  List  IT) 1 (Vpl  ,El  t.Hext) 

endt 

prec  Oeletolvar  ElttLlptCT))|  begin  meed  Elt  a nits  Elt  t-  Elt. Next  endt 

tunc  Laet(LiList(T))piLiet(T)i 
begin 
p t • Lt 

If  p « nd  then  while  p.Next  a ml  So  p I.  p.Noxt  ed  Hi 

ondt 

end  I nodule  LietOef 
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2.3.  Selecting  Representations 

Although  Tartan  treat*  type*  with  different  representations  ••  different  type*,  it  i*  possible  to  use 
the  variant  and  ease  facilities  to  define  generic  types  that  provide  »imiilar  type*  with  different 
representation*.  The  representation  is  fixed  during  translation,  when  the  generic  definition  is 
instantiated. 

This  example  defines  two  alternative  representations  of  queues  It  has  two  generic  parameters. 
The  first  is  the  type  of  the  elements  being  queued,  and  it  is  used  a*  in  the  previous  examples.  The 
second  is  a manifest  constant,  which  is  used  to  select  which  representation  of  queues  is  to  be  used. 
Since  the  variant  is  fixed  during  translation,  there  should  be  no  loss  of  execution  efficiency. 

The  two  representations  of  queues  are  defined  in  terms  of  the  circular  buffers  of  section  Z1  and 
the  lists  of  section  2.2. 


generis  motfcjie  QueueOef  (Titype.  FianumtFis.Flesl]  i 
begin 

•sports  Queue (T1 . | type.  attribute  Size 

Clsar.  Enq,  Oeq.  Eepty,  Full,  I routines 

OCvflt  I exception 

modulo  Lst  is  ListOeftTli 
moAdo  CBf  is  CircularBuf  tersCT]  i 

typo  Queued]  (Sizeilnt)  • 

variant  maniieai  Fst  enumIFix.Flas)  i • F 

[ on  Fl«  ->  CircSut  (Tl  (Size)  an  Fles  -»  ListtT]  ] 

•scoptton  QOvflt  | can  only  bo  re  leap  on  QuouotFis) 

proa  Cl  ear  (result  Qi  Queue  (T])| 
begin 

<aeo  F an  Fis  -»  Clear  IQ  (FIs)  > an  Fles  -»  CleerlQfFles))  seat 
endi 

proa  Enq (ver  Qi  Queue CT),  tenet  Veil  Tl t 

begin 
•see  F 

an  Fin  •>  Append (0 (FIs),  Veil  { on  BufOvfl  •>  tignei  QOvfl  | 
on  Fles  ->  Insert (Lao t (Q (Fles) ) , Veil 

•see 
end  i 


proa  Oeq  (var  Qi  Queued],  result  Veil  T)  i 

begin 
case  F 

on  Fis  -»  Renove(Q(Fis) , Val) 

•"  Fles  ->  begin  vai  i-  O(Fles)  .Data,  Oe  late  IQ  (Fles) ) end 

ease 

endt 

tuna  EnptylQt Queued!  )E:  booieeni 
•mm  P 

an  Fis  ->  E !■  Enpty (Q(Fln) ) 
an  Fles  -»  E I • (Q(Fles)  ■ rail 

eeeei 

tune  Ful  I (Oi  Queue  (Tl  lEibeeleam 
begin 

aaee  F on  Fis  -»  E i • Ful  I (Q(Fls)  .Flxflepl  an  Fles  ->  E > • I alee  eeee 
end« 

end  I nodule  QueueOef 
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2.4.  Safe  Data 

Tartan  doa*  not  provida  indivisiWa  oparatora  for  fatching  and  *101101  vataaa.  If  parallal  procaaaaa 
ora  oparating,  tha  progranvnar  naad*  to  taka  pracautiona  to  anaura  tha  indMaibillty  of  thaaa 
oparationa.  Thia  program  illuatrataa  a rotation  that  will  work  waff  with  typaa  for  which  fatching  and 
storing  tha  whoia  vatua  makaa  sanaa. 


madula  Coapiax  i*  assumad(Coapla><Libl  1 I Coapiaa  axports  typa  Coap 
gawarfa  madul*  SafaOata(Titypa)  > 


aaparfa  SafatTI,  Cat,  Putt  I tgpa  naaa.  fatch  and  atora  routlnaa 

typa  SafatTl  • retard  CLktlaWi,  OataiTlt 

func  Gativar  SiSafatTl  IftiTi  bapn  LockiS.Lkft  R :•  S.Datai  Unlock(S.Lk)  andt 
proa  Puttvar  StSafaCTI,  var  R«T)i  bapn  UockiS.UOi  S.Oata  i»  Rt  Untock(S.Lk) 


andt  ! aodula  SafaOata 

moduia  SafaCoap'ax  a SafaOata (Coapl  t 

var  x.y.zt  SafaCCoaplt 
Putfx,  Coap' (1.  .9. ) > 1 
Put (y.  Coap' <8. ,1.) ) t 
Putfz.  Catixf+Catiylti 


Function  Got  taka*  a SafafT]  (hara,  a Safa(CompD  a*  a var  paramatar.  Sinea  tha  Lk  fiaid  ia  not 
axportad  front  moduia  SafaOata,  Gat  may  uaa  tha  procadura*  Lock  and  Unlock  on  that  latch  in  ordar  to 
protact  tha  fatch. 

Procadura  Put  spaeifia*  var  paramatar*  in  both  position*.  Evan  though  It  doa*  not  altar  R,  a con*t 
•pacification  would  causa  a copy. 

Tha  gonartc  SafaOata  moduia  i«  Inatantlatad  *pad Really  for  numbar*  of  typa  Comp  (tha  typa 
axportad  by  moduia  Compiax). 

In  tha  main  proram,  tha  Comp  constructor  ia  wad  twica  to  ganorata  vataaa  to  atora  in  tha 
variatolaa.  Tha  nawty-conatructad  vataaa  in  tha  call*  on  Put  ara  accaaaibi*  only  in  tN*  program,  ao 
tha  constructor  itsatf  doa*  not  naad  to  ba  tndviaibln.  In  tha  third  assignmant  (call  on  Put),  tha 
addition  ia  tha  addition  for  typa  Comp  axportad  by  moduia  Compiax. 
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3.  Optional  Additions  to  tha  Language 

In  the  course  of  the  Tartan  design,  we  encountered  a number  of  features  that  seemed  attractive  but 
could  not  be  admitted  because  they  violated  either  the  Ironman  requirement  itself  or  the  rule  of 
minimality  that  we  adapted  far  the  design  experiment  We  list  some  of  these  here,  indicating  what 
they  might  add  to  the  language  and  what  they  might  cost 

Abbreviations  for  compound  names.  The  import  rule  as  stated  can  lead  to  the  need  for  a substantial 
amount  of  qualification  because  ail  exported  names,  especially  of  types  and  routines,  are  potentially 
available  pervasively.  A renaming  facility  would  reduce  the  need  for  explicit  qualification.  The 
renaming  facility  might  involve  renaming  on  import,  or  it  might  be  a general  with-efause.  it  would  add 
convenience  and  probably  improve  the  readability  of  the  language.  However,  it  would  introduce  a new 
construct  in  the  language  and  introduce  a new  way  to  create  aliases. 

Less-then-global  storage  pools.  As  the  language  is  defined,  ail  dynamically  allocated  variables  share 
the  same  heap.  It  would  be  possible  to  add  the  ability  to  declare  a local  sub- heap  (zone)  on  the 
stack  and  allocate  designated  dynamic  variables  from  it  instead.  There  might  be  several  zones  active 
at  once,  with  certain  groups  of  variables  sharing  different  ones.  Alternatively,  zones  might  be 
associated  with  blocks  and  all  dynamic  types  defined  in  a block  would  share  storage  from  a common 
zone.  The  cost  is  an  additional  mechanism  and  more  complex  scope  rules.  The  benefit  would  be  more 
control  over  dynamic  variables  and  possibly  more  efficient  storage  recovery. 

Reasonable  and  parameterized  exceptions  An  interrupt-style  exception  that  has  the  semantics  of  a 
procedure  call  (resuming  where  it  was  raised)  would  be  a useful  thing  to  add.  It  would  provide  better 
control  over  many  exception  situations.  Almost  all  the  necessary  mechanism  must  already  be  there  to 
deal  with  the  Notify  command  fie,  the  Terminate  exception)  In  addition,  the  ability  to  past  parameters 
would  be  helpful,  although  it  would  complicate  tha  syntax. 

Richer  control  constructs.  A loop  exit  and  axpiidt  function  return  could  reduce  the  number  of  gotos 
and  awkward  conditional  statements  in  programs.  A richer  collection  of  loop  structures  (downward 
counting,  repeat  with  exitif,  and  aa  on)  would  add  convenience.  However,  each  such  construct  adds  to 
the  size  of  the  language. 

Assertions  in  declarations.  As  presently  formulated,  assertions  are  statements.  It  could  be  useful  to 
permit  them  in  declarations  in  order  to  chock  values  of  attributes  and  to  guard  initialization 
expressions,  (t  would,  however,  require  additional  complexity  in  the  syntax 

User-definable  assignment  As  noted  in  section  1.5.7,  a default  definition  of  assignment  cannot 
anticipate  ail  reasonable  type  definitions  and  all  situations  in  which  assignment  makes  sense.  Only  the 
programmer  has  the  knowledge  to  do  so  Tartan  already  permits  infix  operators  to  be  overloaded  for 
new  types;  there  would  be  little  additional  coat  for  allowing  %*  to  be  overloaded  aa  well. 
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